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ABSTRACT 

A Computer-Aided Software Engineering (CASE) system has been develop^ at the 

Laboratory (CSDL) under the direction of the NASA Langley Research Center. The CSDL CASE tool provides an 
automated method of generating source code and hard copy documentation from functional application enginee g 
SSSSLS? Sc goal is to significantly reduce die cost of developing 

engineering software while increasing system reliability. This paper describes CSDL CASE and d 
demonstrations that used the tool to automatically generate real-time application code. 

INTRODUCTION 

Advanced flight vehicles rely heavily on software to accomplish their missions. The cost of designing, developing, 

software (vehicle guidance, navigation, and control) is becoming an mc = gy 
SSr oSt of total vehicle cost. Until recent years, the lack of appropriate tools to aid in the creation ofsoftware^has 
led 8 to nonuniform development techniques and software that is difficult to maintain, and is either unreliable or ery 

software engineering (CASE) is a t f hnology aimed at automating the 

software development process in order to produce cost effective and reliable software systems. 

One of the major problems associated with the development of real-time scientific and engineering software aside 
Sm efnerTsofSe development issues, is communication among the developers Typically guidance, 
navigation and control (GN&C) algorithmic designs are created by engineers with formal educations in aero^ace 
mechanical electrical, or other pure engineering disciplines, rarely from a software engineering discip me. 
engineers use languages that are indigenous to their disciplines to specify and communicate their designs. TTie 
sp^ifications are printed to software engineers who must interpret them, turn them into a software specification 

and, subsequently, flight code. 

GN&C engineers are not programmers and vice-versa. Consequently, they speak different technical languages. 
CommumcariSi bSween the e groups concerning avionics designs is difficult and prone to error. Usually, 

witlingineers extensively before a software specification adequately represent 
algorithms as conceived by the engineers. One solution to this communication problem is to educate GN&C 
engineers to cope with a diverse set and growing number of programming issues. Most engineers thes ® d ^ s 

to some extent, but to expect them to perfect the art to the degree that programmers have is unreasonable 
ZS solution Is to educate pr^ammers to be able to design GN&C 

engineers' GN&C algorithms, which are becoming more diverse and complex. This solution is also lmpractica^ 
Even programmers who have been developing flight code for years, do not truly comprehend the many static and 
dynamic interactions that must occur for a flight vehicle to carry out its mission. 

Problems are magnified when changes to the code are needed. Proper configuration management practices dictate 
thatchanges should be made first to the engineer's design, then to the software specification, and finally to the code 
Unfortunately this is not always practiced, and documents become inconsistent and incorrect A tool is needed that 
automatically transforms the design specifications developed by GN&C engineers into compilable flight code and 
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APPROACHES TO SOFTWARE DEVELOPMENT 
There are several methods of developing software systems, as shown in figure 1. Early software efforts ffiir 
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Figure 1. Software development methods. 
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COMPUTER-AIDED SOFTWARE ENGINEERING 


Computer-aided software engineering (CASE) is a software technology that began in the early 1980s. CASE s 
aimed at automating the software development process to improve software productivity and quality. The basic 
concept is to provide a set of well- integrated software tools and methodologies that automate the entire software 
development life cycle from analyzing application requirements to maintaining the resulting software system [1]. 

Hundreds of CASE tools have emerged over the last decade. Many of these tools are workstation-based using 
graphics and windowing capabilities to interact with the software developer. CASE tools automate a variety of 
software development and maintenance tasks such as creating structured diagrams and pictonal system specifica- 
tions generating executable code and system documentation, and error checking. Generally a CASE tool covers 
only ^portion of the software life cycle. Most CASE tools also support one or more software development method- 
ology, ^ch as Yourden's structured design [2] or DeMarco's structured analysis [3]. These methodologies use 
notations that are composed of diagrams, graphs, charts, tables, and formal languages. 

CASE offers many enhancements to the software development process. Most of these benefits are _a result of 'the 
automated environment that CASE provides through an interactive graphic user interface. Some of these benefits 
are as follows [1]: 


• enforces software/information engineering, 

• makes prototyping practical, 

• frees developer to focus on creative part of software development, 

• enables reuse of software components (prototypes, data, code, functional designs), 

• simplifies program maintenance and reduces maintenance costs, 

• reduces software development time and cost, 

• improves software reliability and quality, and 

• increases productivity. 


The introduction of CASE technology has changed the software development process Traditional development 
emphasized the later phases of the software life cycle, with 65 percent of the effort placed on the coding and testing 
phases [1]. CASE automates much of the latter part of the software life cycle so more time can be spent on ana ysis 
and design. Table 1 shows the differences between traditional and automated software development 11 J. 


Traditional Development 

Automated Development 

Emphasis on coding and testing 
Paper-based specifications 
Manual coding 
Manual documenting 
Software testing 
Maintain code 

Emphasis on analysis and design 
Rapid iterative prototyping 
Automatic code generation 
Automatic document generation 
Automated design checking 
Maintain design specifications 


Table 1 . Differences between traditional and automated software development. 
CHARLES STARK DRAPER LABORATORY CASE TOOL 


Background 

The foundation of the Charles Stark Draper Laboratory computer-aided software engineering (CSDL CASE) system 
was developed under the Draper Laboratory's internal research and development (IR&D) program [4] It was 
supported bfthe Advanced Launch System (ALS) Advanced Devel^ment Program under the direction of NASA 
Langley Research Center from 1988 - 1989 and was known as ALS CASE [5]. The advancement of CSDL CAS 
continues through the sponsorship of the NASA Langley Research Center and the Draper Laboratory Corporate 
Sponsored Research (CSR) program. 


System Description 

Although there are many CASE tools available commercially, most support general purpose systems development. 
Those that do support real-time scientific and engineering software applications generally do so by providi g 
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automatically produced. The functional specification is input into Ee C^CASE s^ 

^E™"* *** equations, notations fanS to avion 2 and on£l y™m 
designers. The resulting source code is then maintained by modifying the soecificaiinn rhm.mh th» kwuh- 
toefo™. eliminating the need to maintain fnnctional spLifieanS seoSv' 

The architecture of the CSDL CASE tool is shown in figure 2 [71. This architecture which i« imnipmAntaH 
generators 8 W ° rkstation P latf OHn, consists of a user interface, an automatic software designer ^utomaticTode 
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Figure 2. CSDL CASE system architecture. 
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additional ihree panes located at the bottom of the window display, from left lo righl “pdate messages, a menu of 
major specification options, and detailed responses to the selection of a major menu op • 

specifying detailed definidons for them, and then positioning them in the diagram. 
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Figure 3. CSDL CASE user interface window. 

Automatic Sof tware Designer 

statement consists of an assignment to one or morevanablesor a cait p d designer also generates 

which may execnie m pamllel. and which are condi.io.ally 

executed. 


187 







Automatic C ode Generator 
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functions in the software design hl6rarchy 3 " d Creates functions for ^ Procedures and 

Automatic Document Generator 

ge^efatoS^uTS • {on f7 n &’ and Printing . The document 

software design. The geneS Sbff .TT”/? 8 specification used to generate a 
document which reflects*! Sock ScaS ° f P3g6 and 1)0(1 * of lhe 

formatting and printing is performed m , gh generatlon * performed in CSDL CASE, the 

package. The final product is a fully collated document whiHhTn f 3 ^ 00 us ! ng a commer cial publishing software 

sections and subsections, appendices and an index The entire d^ * ^ Page> 131)16 ° f contents - list of figures, 
manual intervention. ' Tbe 6nUre document »s composed and assembled with no 

APPLICATIONS OF CSDL CASE 

73 S 7 D :kStopX^^ applications [9J. The small applications ate a Boeing 

Dynamics ele? Jm^haniil SS ^Kt^S^ten ?" 8 SyS,em ** T ' U,n ,V - a " d a 

the Boeing 737 aircraft, an amom^sexL,^ « “ antoland control system for 

planetary lander. Each of the small aDDlicahnnc replied c e * imu,aUon >. and a guidance and control system for a 
and tens of pages of documentation Each of the mnd • 6 automat ‘ c generation of hundreds of lines of code 
and hundreds of pages™ Xume^ appl, cations generated thousands of fines of code 

CASE application ^ The 737 3utoland s y stem * s bribed below as a representative CSDL 

Boeing 7T7 ^molgnd Svsntm 

CASE. The CSDL CA^E* "specific^t^n^or 3 ^^ 1013 "!' 1 ?' ght contro1 system HO] were generated using CSDL 

implementation and documentation for that implementation 5 Sdllr'T 7?®”® eng . ineered from a FORTRAN 
flowcharts. The autoland system controls oiirh roll „„ Thisdocumcnciuon contained both block diagrams and 

altitude until touchdown aTLSTS? £S^ riT’ ^ for ^ 8,37 f ™"> about 5000 feet 

respiring in approsimatcly 3000 lines of Ada code and 200 '‘ S '" g CSDL CASE " 

wafSite A dt£,rm S The «» «Penmen. 

FORTRAN code. The FORTRAN implementation had nrp^/ gCI j erated Ada code and the manually generated 
structured so that all paths within the design would he exerr c/»H 0U A y undergone exlensiv e testing. Tests were 
code to a time varying set of Input! as U ?“ WaS C ° nduCt6d by sub J ecting FORTRAN 

executed, using the recorded FORTRAN inputs. Outputs were compete SoRTOiS omput^ ** 

CSDL ^^E^s^^«e^r™TO^s^n e t^re , Wc^^grams'that h ^^hp 6 * 1 Ni "r discrepancies were traced to the 
system. Two discrepancies were traced to errors in the FORTO^ode^N l ° *** 3Ut ° matic Programming 
automatic software designer or the automat* generator ^ ^ ^ t0 either the 

? at iS h baSed 0n engineering b,ock diagrams was 
diagrams while minimizing the number of tests The test design H° V ? r the functl °nality expressed by block 
diagram and their connectivity. S g " 15 de P endent on the types of transforms in a block 
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As an extension of this activity, the Ada code was regenerated and targeted for a flight critical computer system. 
The objective of this demonstration was to show that the code produced with CSDL CASE is not only suitable for 
execution on a general purpose computer for prototyping or simulation purposes, but that the code is also 
appropriate for a typical flight critical architecture. The architecture used for this demonstration was the Advanced 
Information Processing System (AIPS) [12] being developed at the Draper Laboratory for NASA Langley. 


AIPS is a set of hardware and software building blocks that can be configured in various ways to form fault-tolerant 
distributed computer system architectures. An AIPS configuration can be used for a broad range of applications, 
including highly-reliable flight critical applications. An AIPS node can consist of a single Fault Tolerant Processor 
(FTP) duplex FTPs, or triplex FTPs, depending on the function criticality and needed reliability. A node can even 
contain one or more Fault Tolerant Parallel Processors (FTPPs), if large capacity throughput is needed for the 
application. Hardware fault detection provides low fault tolerance overhead. System services are provided by an 
operating system written in Ada. The system complexity is hidden from the applications; therefore, the applications 
developer does not have to consider redundancy during application development 

The objective of this demonstration was met The feasibility of using unaltered CASE-generated code on a flight 
critical architecture was demonstrated. First, enhancements were made to CASE to allow the AIPS FTP to be one of 
the architectures available for code generation. This enhancement entailed altering the automatic code generator to 
reflect AIPS system dependencies, particularly to include the appropriate math library instantiations and 
communication routines. 


The steps involved in the actual demonstration are illustrated in figure 4. Specifications for the Boeing 737 autoland 
system were entered into CSDL CASE using the interactive graphical interface (see figure 3). Ada source code 
targeted for the AIPS FTP and detailed documentation were generated. The Ada code was compiled on a Digital 
Equipment Corporation MicroVax using the XDAda compiler [13] and linked with die AIPS operating system. The 
automatically generated code was successfully executed on the AIPS FTP while interacting with a dynamic 
simulation of the Boeing 737 executing on the MicroVax. Proper performance was verified visually during 
execution by a Macintosh display of aircraft state. The displays graphically depicted the aircraft trajectory, attitude, 
and attitude rates. These displays are shown in figure 5. 



Figure 4. Boeing 737 autoland demonstration. 
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Table 2 contains data from one run of the demonstration. Initially, the aircraft was flying level at 1500 feet 
approximately 1 18 knots, and was aligned with the runway. The glideslope was intercepted at 34.8 seconds into the 
simulation and took approximately seven seconds to capture. As is graphically depicted in figure 5, there was no 
overshoot during glideslope capture and no oscillation along the trajectory. During Hare, the system removed all but 
an acceptable amount of vertical velocity (~3ft./scc ) 
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Figure 5. Aircraft status and trajectory displays. 


Environmental Conditions: 

Atmosphere = STD 62 
Winds = None 
Runway = Langley 07 



Initial 

Glideslope 


Condition 

Intercept 

T (sec) 

0.00 

34.8 

Alt (ft) 

1500.00 

1499.75 

Gamma (deg) 

0.00 

0.004 

CAS (kts) 

117.85 

117.73 

Yaw (deg) 

67.33 

66.95 

Pitch (deg) 

3.97 

3.52 

Roll (deg) 

0.00 

-0.07 

HDOT (ft/s) 

0.00 

0.01 


Heading = 67.33 deg. 
Elevation = 9 ft. 

Desired Glideslope = -3 deg. 

Flight Conditions: 


Glideslope 

Near 

Begin 

Capture 

Mid-descent 

Flair 

42.4 

109.6 

175.31 

1461.00 

738.73 

56.04 

-2.995 

- 2.99 

-2.99 

119.75 

118.01 

117.84 

67.17 

66.90 

67.29 

-0.17 

0.90 


0.16 

0.03 

-0.76 

-1.16 

-10.42 

-10.34 


Touchdown 

181.41 

18.87 

-0.87 

108.54 

67.33 


0.26 

-2.76 


Table 2. Boeing 737 autoland experiment data. 
Advanced Guidance Demonstration 


A,D rrr.T: 7 ihC V 1 autoIand c *Penmcnl, the process of demonstrating automatically-generated 
Ada code on a distributed fault-tolerant computer architecture is being pursued. This demonstration is a more 
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extensive experiment to further test this technique for developing a flight critical computer system. The application 
for this demonstration, an advanced adaptive guidance algorithm for a launch vehicle, is much more ambitious. 

During analysis, engineers converge on a single algorithm that they consider to be the baseline design. This baseline 
design is then transcribed into the form of a software specification, since the software specification is typically 
different from the design form used during analysis. Typically, errors are introduced during 1) the initial 
transcription from the analysis representation to the software representation and 2) during maintenance of both the 
analysis and software representations. 

In order to avoid these errors and simultaneously reduce development time by eliminating duplicated effort, the 
algebraic specification capability of CSDL CASE is being modified to accept MATLAB™ scripts. MATLAB is 
an analysis and simulation tool used for the development and test of guidance and control algorithms [14]. This 
feature will allow both analysis and flight code to be developed from a single specification. When iteration on a 
design for analysis purposes is complete, the software specification is, therefore, also complete. The analysis and 
development of the guidance algorithm for the experiment is being performed with MATLAB™. This aspect ot the 
demonstration is intended to show, with MATLAB™ as an example, that it is possible to generate Ada and C code 
from design specifications, and that design analysis and simulation tools will be usable within CSDL CASE. 

Also being demonstrated in this effort is the ability to generate and execute code for a distributed architecture, as a 
network of AIPS FTPs and FTPPs (Fault Tolerant Parallel Processors) will be used for execution. As in the 
previous experiment, the code will be executed on the AIPS while interacting with a dynamic vehicle simulation 
executing on a Micro Vax. The process for this demonstration is shown in figure 6. 


LAUNCH VAX 



Figure 6. Advanced guidance demonstration on distributed AIPS. 

FUTURE ACTIVITIES 

Future activities include the development of an Automated Testing Subsystem, a Software Design Methodology 
User Interface, and the inclusion of formal semantic representations for software designs. Commercialization is also 
being pursued. 
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Automated Testing Subsystem 

Automating testing would involve automating the five steps common to testing, namely: 1) design; 2) setup- 3) 
execution; 4) analysis; and 5) documentation. Design is the determination of how the code will be exercised and 
monitored in order to ensure that the code complies with its corresponding requirements. Setup is the process of 
collecting and assembling all of the components that are specified in a test design. These components can include 
source code, object code, load modules, simulators, input data, specifications on data to be collected during 
execution, and expected test results. Execution is the process of downloading a load module to a target environment 
initiating execution, monitoring and collecting data, and terminating execution. Analysis is the process of 
determining if actual results agree with expected results. Documentation, obviously, consolidates information in the 
previous four steps for dissemination and review. Clearly, automated design and thorough analysis are the most 
complex of the described steps. The remaining three steps and simple analysis are candidates for an initial prototype 
automated testing system. y 

Automated test setup will allow test data to be specified for each transform (or selected transforms) in an application 
design. Test dnver code wdl automatically be generated for the supplied test data. For execution, a load module 
will be automatically developed for the target environment. A capability will be provided to automatically compile 
Imk, and execute test code, and then monitor execution on the user’s workstation while recording data. This process 
should be controlled from the user’s workstation, even if the code is executed on another machine. Simple analysis 
will be accomplished by comparing achieved results with desired results. The results and discrepancies will be 
documented in a test report. The display screens and documentation could both vary in complexity from the output 
of numeric values to graphs, plots, or complex visualization techniques. Naturally, an initial prototype will employ 
the more simple means of data display. ^ w 

Software Design Me thodology User Interface 

The objective of the Software Design Methodology User Interface (SDMUI) is to allow software designers to 
qiecify a software design methodology and automatically apply that specified methodology to a functional design 
Software design methodologies that are specified through this SDMUI, will be able to be reused on different 
functional designs. It will be possible to reconfigure a functional specification from one software design into 
another. Reconfigurations retain the specified functionality of an application design but alter elements of a software 
design such as memory utilization, execution time, modularity, and compile time in order to optimize execution on a 

rePreS '”' a ' i «” S Wi " "O' 0 ™ «*«” sy«en, conamms. 

Formal Semantics 

Formalisms for representing the semantics of software designs will be investigated. Formalisms will be used to 
ve op a language for representing software designs and methodologies for manipulating software designs. All 
tpulated versions of a software design should contain the same functionality but would consume different 
computationa 1 resources (i.e., functionally equivalent designs would be represented in different, but equivalent 
software designs dependent on the target machine). The design specified by a user of CSDL CASE is the engineer’s 
software application’s functionality. As long as the top-level inputs and outputs are the same, it does not 
matter how the software implementation of this application is executed. It is the intent to be able to transform one 

IHfrlr . CXeC l!, tin i g 3 target so ^ lware a PP Ilcadon int0 anoft 1 " and to be able to demonstrate with mathematical rigor 
that the two methods are equivalent. B 

Commercialization 

It is the intent of NASA Langley and the Draper Laboratory to pursue commercialization of CSDL CASE in 
cooperation with a third party. Ideally, present capabilities would be available commercially, supported by a 
commercial software vendor. The tool would also remain a research vehicle for NASA Langley and the Draper 
Laboratory to pursue software automation issues like those described in this section 
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SUMMARY 


The CSDL CASE system views software design, development, and maintenance from the perspective of the 
application engineer. Unlike most code generators which address the generation of source code from software 
designs, this approach addresses automated code and documentation generation from specifications of functional 
application designs. The user interface provides a natural design technique for the specification of real-time 
software by allowing the functional specifications to be input as hierarchical engineering block diagrams, a notation 
familiar to application engineers. With this technique, rapid system development and prototyping are possible. 
Maintenance concerns are reduced since both the code and documentation are maintained by changing the graphical 
specification Software reliability and productivity are increased because of the reduction in manual operations, the 
consistency and completeness checking provided by the system, the automatic translation of specification to code, 
and the support for reuse of specifications. The application of this CASE tool to many real avionics designs has 
driven the development of the tool and has proven the viability of the approach. It is felt that CSDL CASE has a 
place in the commercial arena, particularly in the control systems design environment. 
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